The Machine to Machine (M2M) communication system consists of individual M2M nodes and an underlying network. The M2M nodes communicate with each other through the underlying network. An M2M node comprises at least one Application Entity (AE) or one Common Services Entity (CSE). AE is the logical unit that executes the M2M application and the CSE is the logical unit that manages and serves the application. An underlying Network Services Entity (NSE) provides the CSE with device management, location service, equipment trigger and other services, such as home subscriber server (HSS), MTC-InterWorking Function (MTC-IWF) entity, etc.
The communication between M2M applications is implemented through the interworking between CSEs. The M2M applications need to register with the CSEs, and the CSEs also need to register with each other, so that the interworking between the M2M applications can be implemented through the communication between the CSEs. FIG. 1 is a schematic diagram of the architecture of an M2M system. As shown in FIG. 1, in M2M system architecture, the application node is an end execution node 1, such as a smart meter, a temperature measurement and control sensor, fire alarm, a smart home appliance, etc.; a middle node (MN) is a middleware (for example, a gateway) connecting an end execution node to a network side server; an infrastructure node (IN) is a network side server, and an application registered with an infrastructure node, that is, an IN-AE, may be a management platform of an M2M service provider (M2M SP). Application nodes can be classified into two categories according to their functions: nodes that comprise CSE and nodes that do not comprise CSE. An Application Dedicated Node (ADN) comprises at least one AE and does not comprise a CSE; an application service node (ASN) comprises at least one AE and one CSE.
The “group management” common services function in the CSE enables the M2M system to perform batch operations on multiple devices, applications, or resources in a group. A group (<group>) resource represents a group of the same or multiple types of resources, and it is configured that batch operations are performed on resources represented by an attribute of the member identifications (memberIDs, the attribute representing the members of the group). The resource represented by the attribute of the member identifications is abbreviated as member resource herein. The group resource further comprises directly forwarding point (<fanOutPoint>) that allows operations to be performed onto the virtual resources of the resources represented by the members. When an operation request is sent to the resources of <fanOutPoint>, a operation request for triggering is distributed to the members of respective group resources represented by the attribute memberIDs, while the response to the operation request from each member is collected and fed back to the initiator of the operation request. That is, when a remote CSE sends a forward request to a local CSE, the local CSE acquires to-be-forwarded member resources from the group resources and feeds same back to the initiator, the initiator transmits the to-be-forwarded member resources to the local CSE again, which will add the to-be-forwarded member resources into target member resources for update. The steps of forwarding the member resources are cumbersome and difficult to meet real-time requirements, and larger signaling overhead may occupy more network resources and may cause network congestion. These problems are more obvious for M2M applications that have a large number of member resources, a large amount of information transfer between member resources and high real-time requirements.
In summary, the existing process of forwarding the attribute information of member resources is cumbersome, has low real-time efficiency and large signaling overhead, and may cause network congestion due to the occupancy of network resources.